Current non-integrated software development environments are of limited support in completing software development projects. A lack of transition support between the development environments and the disconnected tools slows completion of projects. Inadequate integration includes inability to access particular software development tools, inability to track tool objects used and relied upon, and inability to track the impact of tool actions upon subsequently used software development tools. One kind of access problem occurs in transitioning from building a particular program to debugging it. If after building a particular program, debugging is desired, a completely different program invocation must separately be undertaken. If the user forgets the debugger name or location, the transition between building and debugging is blocked and software production stops.
Inefficiency and ineffectiveness further result when a particular programming environment fails to track objects pertaining to a recently used software tool. Text-based compilers, for example, do not remember most recently compiled files. Graphical tools similarly do not track file or macro objects which were recently used. The user is thus forced to enter particular object references for the earlier-used tool by manipulating a file chooser dialog box, for example, each time a follow-on tool is invoked. Thus, if a user wants to add desired new buttons to a graphical user interface (GUI) housed in an existing GUI builder file, the user typically must first bring up the GUI builder and "browse" its file hierarchy to get the path to the GUI builder file. This takes time and creates errors, consuming valuable resources.
Tool tracking problems further occur when a tool performs an action such as creating a file as a prelude to follow-on action by another tool. Multiple tools need to interact, such as when a make tool invokes a compiler linker to produce a program to be separately debugged. Tool interdependence is palpable when a collector produces an experiment to be processed separately by an analyzer, or when a GUI builder produces a make file to be processed separately by a make tool. The first acting tool does traditionally not inform follow-on tools operating on newly created objects of results of earlier processing. Accordingly, the user must intervene to specify applicable objects and object information tool by tool. In the meantime, the follow-on program tool languishes unproductively.
Known integrated software development environments such as Symantec's integrated C development environment or Borland's Turbo C environment, permit invocation of tool sets. However, the sets of tools invoked in such environments are pre-specified and already integrated within an applicable development environment by the creator of the development environment ab initio. The integration of additional tools which a user may want to use in connection with the particularly selected integrated software development environment is not permitted. A Sun Microsystems product called SPARCworks Manager, for example, puts severe restraints on third party tool integration. Limited integration of this product exists to allow centralized tool invocation and coordination between particular tools and a small set of actions including Restore, Minimize, Hide and Show messages. In X Windows, messages are sent by a window manager to applications to inform them that an X Windows session is ending. However, such minor information passing is of limited significance.